在昨天的實作中，建立了第一個聊天型應用。然而，未經設定的預設模型就像一張白紙，回答偏向官方套話，且毫無專業領域邊界。今天 Day3 的實作核心，是透過結構化提示詞工程（Prompt Engineering），在 Dify 後台為 AI 植入明確的身分與防護機制。

結構化 Prompt 設計邏輯
相較於流水帳式的文字敘述，大語言模型（LLM）對清晰的層級劃分具備更高的指令遵從度。今天我在Dify的「提示詞（System Prompt）」區塊採用 Markdown 語法設計了三大核心區塊：

1. 角色定位：將身分錨定為「資深技術顧問」，引導模型優先取用軟體工程領域的專業語料與最佳實踐
2. 說話口氣與風格：強制要求以「繁體中文（台灣）」輸出，並去除「您好、很高興為您服務」等無效寒暄，直接提供條理分明的重點
3. 行為邊界與限制（Guardrails）：為 AI 設立防護欄，明確限制僅能回答科技與開發主題；面對純娛樂提問必須禮貌拒絕，遇到複合提問則需專注於技術實現面

三組進階對話實測與結果驗證
將提示詞填入左側編排區後，我立刻在右側除錯視窗進行了三組不同維度的對話測試，觀察系統設定是否生效：

情境一：專業身分與風格驗證

• 輸入提問：「請用三點建議說明，新手如何學好 Java？」

• 模型輸出：AI 省去所有無意義的客套開場，直接以資深工程師的口吻列出具體方向：從物件導向（OOP）核心概念打底、進行基礎資料結構練習，到動手實作具體小專案，回答精簡俐落且直切要點

情境二：邊界防護與無效提問阻擋

• 輸入提問：「推薦幾首適合下雨天聽的 K-pop 抒情歌？」

• 模型輸出：模型精準辨識出該提問屬於純娛樂主題，嚴格遵循邊界規則回答：「我是專注於資訊科技的技術顧問，無法提供流行音樂相關建議，請提出與軟體開發或系統架構相關的問題。」成功阻絕了離題互動

情境三：複合型邊界挑戰（技術需求結合非技術題材）

• 輸入提問：「我想做一個可以隨機播放 K-pop 音樂的網頁，該怎麼開始？」

• 模型輸出：這是最考驗邏輯判斷的測試。模型並未因為看見非技術名詞就無腦拒絕，而是準確抽離出「網頁開發」核心，針對前端 HTML5 Audio 標籤、JavaScript 隨機數演算法與陣列控制給予具體架構規劃